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FOREWORD 


This  report  was  prepared  by  the  Value  Engineering  Staff  at  System 
Development  Corporation  (SDC),  2500  Colorado  Avenue,  Santa  Monica,  California, 
under  contract  with  the  416M/P/418L  Air  Weapons  Surveillance  and  Control  SPO, 
Electronic  Systems  Division,  L.  6.  Hanscom  Field,  Bedford,  Mass.  It  describes 
the  Value  Engineering  effort  on  the  BUIC  III  contract  for  the  period 
1  July  1967  to  30  November  1967. 

The  author  is  indebted  to  M.E.  McCormick,  who  ably  assisted  in  the 
implementation  of  the  VE  Plan,  and  in  addition,  provided  a  technical  review 
of  this  report. 

This  Technical  Report  has  been  reviewed  and  is  approved. 


L.  C.  Allard,  Colonel  USAF  / 
System  Program  Director  v 

Air  Weapons  Surveillance  &  Cantral 
System  Program  Office  (416M/P/418L) 
Electronic  Systems  Division  AFSC 
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ABSTRACT 


This  document  contains  a  report  on  the  application  of  Value  Engineering/ 

Value  Analysis  techniques  to  the  BUIC  III  contract,  which  is  basically  a 
software  (computer  programming)  contract.  It  describes  the  procedures  used, 
the  problems  encountered,  and  recommendations  for  VE  on  future  software  contracts. 
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SECTION  I 


I.  INTRODUCTION 

Within  the  last  twenty  years  computer  programming  has  mushroomed  into 
a  multi -mi  11  ion  dollar  industry.  As  with  most  hastily  developed  industries, 
this  phenomenal  growth  has  been  accompanied  by  a  great  amount  of  technical 
enthusiasm  and  a  corresponding  lack  of  control  and  standardization.  As 
experience  is  gained  in  program  production,  it  is  apparent  that  many  of  the 
business  management  techniques,  with  appropriate  modifications,  are  applicable 
to  program  production.  One  of  these  management  techniques.  Value  Engineering, 
has  been  a  part  of  government  hardware  contracts  for  some  time. 

The  BUIC  III  contract,  dated  1  October  1966,  received  by  SDC  was  a  Cost  Plus 
Fixed  Fee  (CPFF)  contract  and  was  in  excess  of  $1,000,000.  Pursuant  to  Armed 
Services  Procurement  Regulation  (ASPR)  1-17,  a  Value  Engineering  Program 
Requirement  clause  was  levied  upon  the  Contractor.  Prior  to  receipt  of  this 
contract,  the  Contractor:  (1)  had  not  previously  been  involved  with  any 
Value  Engineering  (VE)  requirement,  and  (2)  the  application  of  Value 
Engineering  techniques  to  the  Contractor's  prime  area  of  interest — computer 
program  development  and  production — was  open  to  question.  With  these  two 
potential  problem  areas  in  mind,  the  Contractor  proceeded  to  generate  a 
Value  Engineering  Plan  which  described  his  outline  for  an  in-house  training 
and  education  program,  for  selection  of  high-cost  contract  areas  for  analysis, 
and  for  Value  Analysis  procedures. 

To  our  knowledge  the  BUIC  III  contract  was  the  first  computer  program  contract 
in  which  the  ASPR  Value  Engineering  program  clause  was  applied.  This  interim 
Technical  Report  contains  the  contractor's  VE  plan  as  applied  to  the  contract, 
the  initial  results  of  the  implementation  of  the  VE  plan,  the  problems 
encountered,  and  recommendations  for  future  actions. 

II.  DEFINITION  OF  TERMS 

A.  Value  Engineering 

"ASPR  1-17,  Revision  23,  dated  1  June  1967,  defines  Value  Engineer¬ 
ing  as  "a  systematic  and  creative  effort,  not  required  by  any  other  provision 
of  the  contract,  directed  toward  analyzing  each  contract  item  or  task  to 
ensure  that  its  essential  function  is  provided  at  the  lowest  overall  cost." 

B.  Value  Analysis 

Value  Analysis  is  the  assessment  of  the  value  of  a  product,  process, 
or  procedure,  including  close  scrutiny  and  definition  of  its  functions  and 
comparative  costs  of  performing  those  functions  in  other  reasonable  ways. 
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c. 


Value  Assurance 


Value  Assurance  results  from  the  application  of  Value  Engineering 
techniques  during  the  initial  creative  phases  of  a  functional  process.  Value 
Assurance  efforts  are  intended  to  assure  a  high  value  product  or  process  before, 
rather  than  after,  production  begins.  It  parallels  the  purpose  and  meaning 
of  other  similar  phases  such  as  reliability  assurance  and  quality  assurance. 

D.  Software 


As  used  in  this  report,  software  encompasses  those  procedures, 
documents,  and  activities  required  for  the  development,  design,  production, 
testing,  and  updating  of  a  computer  program  system,  including  the  training 
procedures  required  to  operate  the  system. 
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SECTION  II 


III.  IMPLEMENTATION  OF  THE  VALUE  ENGINEERING  PLAN 

The  proposed  Value  Engineering  Plan  received  approval  in  May  1967. 
Contract  coverage,  however,  did  not  begin  until  1  July  1967.  The  plan  out¬ 
lined  the  main  VE  functions  to  be  performed. 

A.  Training 

Since  the  contractor's  prior  exposure  to  Value  Engineering  was 
minimal,  a  basic  10-hour  seminar  was  provided  for  some  60  selected  super¬ 
visory  and  technical  personnel.  References  2,  3,  4,  and  7,  and  14  in 
Appendix  B  provided  the  base  for  the  seminar.  The  10-hour  seminar  consisted 
of  five  2-hour  sessions.  The  outline  for  the  sessions  is  contained  in 
Appendix  A. 

B.  Organization 

An  attempt  was  made  to  employ  Value  Engineers  who  had  a  background 
in  software  production.  None  were  available  and  two  VE  personnel  were  chosen 
from  in-house.  Each  had  a  minimum  of  ten  years  experience  in  program  or 
training  materials  production,  and  both  had  previous  experience  in  cost- 
effectiveness  and  quality  assurance  work.  In  the  belief  that  morale  holds  up 
better  and  that  there  is  a  resulting  better  chance  of  getting  Value  Engineer¬ 
ing  changes  accepted  in-house  if  the  individuals  actually  performing  the  job 
participate  in  the  Value  Analysis,  SDC  chose  the  staff  approach  method  of 
organization.  After  investigation  of  areas  where  savings  were  deemed 
possible,  study  teams  were  organized,  with  representation  from  system  design, 
program  design,  programming,  and  Value  Engineering  areas. 

Depending  upon  the  functional  area  being  investigated,  the  study  team  was 
headed  by  the  most  cognizant  member  of  the  team,  with  the  Value  Engineering 
member  either  heading  the  study  or  simply  participating  in  it. 

C.  Value  Analysis 

As  mentioned  previously,  funding  for  the  Value  Engineering  effort 
did  not  begin  until  1  July  1967.  This  late  start  limited  the  effectiveness 
of  the  proposed  Value  Engineering  Plan.  To  achieve  optimum  results.  Value 
Engineering  personnel  must  participate  in  the  generation  of  the  contract 
proposal,  and  a  detailed  Value  Engineering  Plan,  complete  with  goals  and 
costings,  should  be  a  part  of  the  proposal.  It  is  most  important  that 
immediately  after  contract  negotiations,  the  Statement  of  Work  be  thoroughly 
analyzed  by  Value  Engineering  personnel  for  high-cost  areas  and  for  assign¬ 
ment  of  VE  teams  for  functional  analysis.  Predicted  or  potential  savings 
should  not  be  made  until  this  initial  analysis. 


3 


Since  it  was  not  possible  to  follow  this  schedule  for  BUIC  III,  the  VE  effort 
was  at  a  distinct  disadvantage  in  attempting  to  analyze  the  technical 
functional  areas,  because  program  requirements  and  design  were  set  in  concrete 
and  any  changes  to  them  were  apt  to  place  the  contract  schedule  in  jeopardy. 

In  at  least  one  area  of  analysis,  a  potential  savings  was  deemed  possible; 
but  upon  further  investigation,  it  was  discovered  that  the  items  in  question 
were  already  produced  using  the  old  method,  and  there  was  to  be  no  further 
production  under  the  terms  of  the  contract! 

D.  Selection  of  Value  Engineering  Tasks 

For  VE  purposes,  the  computer  program  production  process  can  be 
divided  into  three  areas  for  analysis: 

.  The  means  of  inputting  data  to  a  computer. 

.  The  processing  of  data  by  the  computer  (the  computer  program). 

.  The  outputting  of  the  description  and  use  of  the  program  system 
(documents) . 

Realizing  that  pure  programming  system  functions  are  too  far  downstream  for 
Value  Analysis,  the  Value  Engineering  effort  concentrated  on  the  analysis  of 
computer  inputs  and  outputs.  Several  VE  studies  were  undertaken  with  the 
following  results. 

1 .  Use  of  optical  scanner  as  an  input  device.  The  present  method 
of  using  punched  cards  to  initially  input  data  to  a  computer  was  analyzed. 
Optical  scanning  of  specially  typewritten  materials  was  studied  for  potential 
cost  savings.  The  study  indicated  that  available  scanners  do  not  lend  them¬ 
selves  to  present  SDC  input  requirements.  As  further  industry  advances  are 
made,  scanners  should  be  examined  again  for  application  to  BUIC  III  inputs. 

2.  Standardization  of  input  manuscripts.  Presently  a  variety  of 
colorcoded  and  columnated  manuscripts  are  used  to  input  data.  A  study  is 
currently  underway  to  determine  if  a  standard  coding  manuscript  of  80  columns 
can  be  used.  Specially  made  plastic  overlays  will  be  used  to  specify  columnar 
headings.  The  present  average  cost  of  manuscripts  is  $  .04  each.  Anticipated 
cost  of  a  standard  manuscript  is  $  .01. 

3.  Use  of  a  program  to  produce  documents.  An  automatic  means  of 
producing  and  updating  program  documentation  (Text  90)  was  analyzed.  A  VECP 
for  using  Text  90  for  each  of  the  three  BUIC  III  CEIs  was  submitted  to  the  SP0 
for  consideration.  It  is  significant  to  note  that  had  these  three  VECPs  been 
proposed  and  approved  in  the  early  stages  of  the  contract,  savinqs  on  the 
order  of  $70-80,000  would  have  resulted  instead  of  the  $9,000  as  estimated  in 
the  VECPs.  The  importance  of  performing  the  Value  Analysis  as  early  in  the 
contract  as  possible  cannot  be  overemphasized.  These  VECPs  were  disapproved 
by  the  SP0  because  the  contractor  did  not  provide  for  turnover  and  updating 

of  the  Text  90  program  as  part  of  the  VECP. 
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4.  Elimination  of  unnecessary  training  tapes.  Elimination  of  cross- 
tell  simulation  tapes  for  training  purposes  was  examined.  Although  it  was 
found  that  the  tapes  could  be  replaced  by  cards  at  a  savings,  there  was 
insufficient  remaining  production  to  amortize  implementation  costs. 

5.  Use  of  microfiche  in  lieu  of  hard  copy  documents.  The  use  of 
microfiche  copy  is  currently  being  examined.  Initial  page  costs  of  $  .40  for 
hard  copy  vs  $  .05  for  fiche  and  reproduction  costs  of  $  .0125  for  hard  copy 
vs  $.003  for  fiche  make  the  potential  savings  realizable.  It  is  anticipated 
that  significant  savings,  both  in  the  BUIC  III  and  future  contracts,  will 
occur  by  the  substitution  of  microfiche  for  a  hard  copy  document.  All  users 
of  the  microfiche  will  be  provided  a  reader,  and  all  personnel  will  have 
access  to  a  reader-printer,  if  a  hard  copy  reproduction  is  necessary. 

Because  of  time  constraints,  it  was  not  possible  for  VE  personnel  to  analyze 
the  BUIC  III  program  system  prior  to  its  production.  Program  system  functions 
can  and  should  be  analyzed  by  trained  VE  personnel.  The  functions  of  a 
computer-based  air  defense  command/control  system  generally  include  the 
following: 

1.  Executive  control . 

2.  Environment  definition. 

3.  Identification. 

4.  Sensor  data  processing. 

5.  Console  switch  interpretation. 

6.  Manual  data  insertion. 

7.  Digital  and  situation  displays. 

8.  Weapons  control  and  assignment. 

9.  Weapons  guidance. 

10.  Data  link  input  and  output. 

11.  Communication  message  make  up. 

12.  Height  information  processing. 

13.  Telling  information  to  adjacent  and  higher  commands. 

14.  Recording  of  vital  data. 

15.  Simulation  for  exercising  purposes. 

16.  Restart  capability. 

The  Value  Engineer  should  examine  each  one  of  those  functions,  asking  the 
following  questions. 

1.  Are  common  program  subroutines  written  only  once  and  accessible 
by  all  computer  program  components  (CPCs ) ? 

2.  Is  the  data  base  made  up  compactly  and  for  ease  of  later 
updating? 

3.  Do  functions,  subfunctions,  or  subroutines  presently  exist  in 
another  program  system,  which  can  be  used  with  little  or  no 
modification? 

4.  Are  CPCs  broken  into  the  best  possible  elements?  Can  some  be 
combined?  Are  they  operated  in  the  least  time-consuming  sequence? 
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5. 


Are  table  lookups  or  direct  conversion  routines  the  best  means 
of  performing  a  function? 

6.  Can  any  of  the  CPCs  be  coded  using  a  higher-order  language?  Is 
it  worthwhile  to  do  this  for  certain  CPCs  and/or  refine  them 
manual ly? 

7.  Are  the  number  of  interfaces  between  CPCs  and  CEIs  at  a  minimum? 

8.  Does  the  Contract  Data  Requirements  List  contain  unnecessary 
data  items?  Can  the  quantities  of  data  items  be  reduced? 

9.  Are  all  test  procedures  necessary?  Can  tests  for  standard 
program  routines,  that  have  previously  undergone  testing,  be 
deleted  or  reduced  in  scope? 

10.  In  a  multiple-site  system,  are  installation  teams  required  at 
each  facility,  or  can  a  test  team  be  located  at  a  central 
source  to  provide  service  to  all  sites? 

11.  If  training  materials  (simulation  tapes,  exercise  maps,  lists, 
scripts,  cards,  etc.)  are  a  CDRL  requirement,  can  they  be 
reduced  in  number  or  can  acceptable  substitutes  be  provided? 
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SECTION  III 


IV.  PROBLEMS 

In  addition  to  the  usual  roadblocks  encountered  in  attempting  to  apply 
V E  to  software,  others,  perhaps  unique  to  the  software  industry,  came  up 
during  the  implementation  of  the  VE  Plan.  Some  of  these  can  be  overcome 
through  training  and  by  writing  enough  programs  for  all  the  available  computers, 
so  that  programming  primarily  becomes  a  task  of  putting  together  already 
programmed  functions.  As  the  roadblocks  were  uncovered  by  the  VE  staff, 
discussions  were  held  with  the  technical  personnel  to  overcome  the  blockages. 

A  short  description  of  each  roadblock,  with  the  VE  response,  follows. 

A.  Programming  as  a  Unique  Effort 

Because  of  the  unique  requirements  (mission,  equipment,  personnel 
of  the  BUIC  III  command/control  system),  programming  is  to  a  large  degree  a 
one  of  a  kind  effort.  Except  for  the  general  logic  involved,  programs  cannot 
be  simply  taken  off  the  shelf  and  put  together  to  meet  the  software  require¬ 
ments. 


VE  Response 

Any  task  function,  even  a  unique  one,  can  be  laid  out  in  a  VE  job  plan.  When¬ 
ever  the  details  and  related  costs  of  a  task  function  are  laid  open  for 
analysis,  it  is  a  rare  occasion  when  the  analysis  does  not  lead  to  lesser 
costs.  In  instances  where  costs  are  not  reduced,  close  scrutiny  of  each 
program  component  can  result  in  increased  performance  and/or  reduced  operating 
size. 


B.  Lack  of  Repetitive  Production  Costs 

In  any  hardware  contract  where  multiple  assemblies  are  specified, 
a  relatively  small  VE  savings  per  assembly  can  result  in  substantial  overall 
savings.  For  example,  in  a  contract  calling  for  5,000  identical  assemblies, 
a  savings  of  only  $10  per  assembly  results  in  a  total  of  $50,000  saved.  The 
$10  savings  per  unit  can  probably  be  realized  without  any  disruption  to  the 
work  force,  since  the  savings  in  materials  requires  a  change  in  the  type  or 
quantities  purchased  and,  in  manpower,  a  reduction  in  production  time  which 
can  be  used  to  produce  the  same  or  other  items  for  another  customer.  In 
short,  it  is  not  necessary  to  have  large  individual  VE  changes  in  hardware 
projects  to  produce  cost  reductions.  This  does  not  hold,  however,  in  the 
production  of  computer  programs.  In  command/control  systems  such  as  BUIC  III, 
an  overwhelming  proportion  of  contract  dollars  is  used  in  the  production  of 
the  initial  computer  program.  Even  though  40  to  50  copies  of  the  master  tape 
containing  the  computer  program  may  be  required,  the  cost  of  reproducing  these 
tapes  is  minute  compared  to  the  original  production  costs. 
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VE  Response 


Because  of  this  unusual  proportion  of  production  costs,  VE  analyses  to  be 
worthwhile  must  result  in  significant  savings  per  single  application.  SDC 
estimated  this  figure  to  be  a  minimum  of  $5,000;  this  estimate  was  used  to 
take  care  of  any  error  and  delay  in  the  implementation  of  a  change.  Again, 
a  VE  job  plan  is  effective  in  bringing  to  light  potential  cost  savings.  While 
it  is  true  that  some  of  the  savings  may  be  small  because  of  the  one-of-a-kind 
production  nature  of  software,  they  can  result  in  a  substantial  savings  if 
lumped  together  and  used  to  reduce  overall  contract  costs. 

C.  Ratio  of  Production  Costs 


The  relation  between  the  dollars  spent  on  contract  wages  and 
salaries  and  those  spent  on  materials  also  presents  an  unusual  proportion.  In 
SDC  Proposal  355(D)  on  the  BUIC  III  contract,  an  overwhelming  proportion 
(93.6%)  of  the  cost  was  for  direct  salaries,  burden  (supervisory  staff,  fringe 
benefits,  administrative  overhead),  travel,  and  field  allowances.  Any  large 
VE  savings  must  come  out  of  this  wage  and  salary  pot.  Since  the  assets  and 
productive  talents  of  any  software  organization  are  represented  by  a  reservoir 
of  professional  skills,  any  really  large  and  significant  VE  change  will  probably 
result  in  a  disruption  of  these  people  either  by  reorganization  or  termination. 
There  is  not  usually  a  "backlog  of  orders"  to  fill  the  void  created  by  such 
an  event.  Contracts  are  let  with  specific  start  and  end  dates  and  must  be 
staffed  as  called  for  in  the  contract.  Unless  a  contractor  is  engaged  in  many 
contracts  at  the  same  time,  it  is  impossible  to  smooth  out  the  production 
peaks  and  valleys. 


VE  Response 

While  this  problem  creates  a  challenge  for  any  management,  it  can  be  overcome 
by  a  change  in  management  organization,  planning,  and  costing  techniques. 

For  future  contracts,  SDC  has  organized  software  capability  pools  such  as 
specification  writing,  programming,  and  testing.  With  this  kind  of  organization 
several  contract  tasks  may  be  processed  in  parallel.  By  further  dividing 
functional  tasks,  more  than  one  contract  can  be  serviced  by  the  same  individual 
"simultaneously."  For  example,  rather  than  providing  a  single  cost  charge 
number  for  a  large  task  function  such  as  the  production  of  the  Air  Defense 
Program  CEI,  this  large  task  can  be  broken  down  into  smaller  task  functions 
such  as  Part  I  Specification  production.  Part  II  Specification  production,  etc. 
Each  of  these  subtasks  can  further  be  broken  down  into  subsubtasks  such  as 
data  gathering,  data  coordination,  draft  specification  publication,  draft 
specification  review,  and  final  specification  publication.  Costs  and  schedules 
are  assigned  and  evaluated  for  each  subsubtask.  A  master  schedule  of  tasks 
is  monitored,  with  personnel  assigned  on  a  task,  rather  than  a  contract  basis. 
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D.  Lack  of  Detailed  Costs 


Although  the  term  "production"  is  used  in  the  computer  program 
development  process,  the  production  process  is  more  in  the  nature  of  a  service, 
for  each  program  system  represents  a  specific  solution  to  a  specific  require¬ 
ment.  If  in  large  contracts  it  is  reasonable  to  assume  that  some  functional 
areas  are  overcosted  and  overspecified,  is  it  not  reasonable  to  assume  that 
some  functional  areas  have  been  undercosted  and  underspecified?  While  the 
contractor  gets  to  share  in  the  savings  of  an  approved  VECP,  who  gets  to  share 
in  the  losses  that  he  may  sustain  because  of  underestimating  costs? 

VE  Response 

Breaking  down  task  functions  into  subtasks  and  subsubtasks  will  permit  a  more 
accurate  assessment  of  costs,  in  both  proposal  and  contract  performance.  If 
programs  or  program  functions  can  be  eliminated  without  degrading  the  Air 
Defense  mission,  they  should  be  the  subject  of  a  VE  study  team. 

E.  Lack  of  Contract  Details 


By  its  very  nature  a  command/control  computer  program  contract  cannot 
be  specific;  the  numbers  and  kinds  of  programs;  the  numbers  and  kinds  of  data 
tables,  etc.,  are  the  tasks  to  be  provided  under  the  terms  of  the  contract. 
Although  the  BUIC  III  Statement  of  Work  did  specify  the  gross  program  systems 
to  be  provided--the  Air  Defense  Computer  Program,  the  System  Exercise  Computer 
Program,  and  the  Utility  Computer  Program — it  did  not  specify  further  details 
concerning  the  construction  of  these  program  systems.  To  qualify  as  a  VECP,  a 
change  must  save  money  and  require  a  change  to  the  contract.  By  definition 
then,  changes  to  programming  techniques,  methods,  tables,  registers,  etc., 
would  not  qualify  as  VECPs. 


VE  Response 

Although  Value  Engineering  Change  Proposals  may  be  limited  because  of  the 
definition  of  a  Value  Engineering  Change,  the  Contractor  can  reduce  the  total 
contract  costs  through  Value  Analysis  techniques. 
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SECTION  IV 


V.  SUMMARY  AND  RECOMMENDATIONS 

In  spite  of  the  unique  roadblocks  described  previously,  software  is 
amenable  to  the  techniques  of  Value  Engineering.  Because  of  the  non-repeti¬ 
tiveness  and  the  one-of-a-kind  nature  of  software,  VECPs,  as  currently  defined, 
must  necessarily  result  in  large  individual  savings.  High  dollar  VECPs  are 
therefore  unlikely,  particularly  during  the  acquisition  phase  of  the  software 
system;  however,  application  of  VE  techniques  early  in  the  system  life  cycle 
can  result  in  intangible  savings  through  improved  performance  and  efficiency, 
or  even  of  assuring  contract  performance.  These  savings,  though  intangible, 
can  well  be  worth  any  measurable  dollar  savings.  For  example,  a  frequent  cause 
of  complaint  by  a  program  system  user  is  that  the  system  does  not  perform  accord¬ 
ing  to  specifications.  Program  systems  are  so  interleaved  and  interwoven 
that  the  later  this  is  discovered,  the  more  difficult  and  more  costly  it  is  to 
remedy.  By  having  VE  personnel  participate  in  the  program  design  phase,  the 
probability  of  this  occurring  is  lessened. 

The  greatest  VE  savings  can  occur  in  the  preproposal  period.  A  well-trained, 
conscientious  VE  staff  can  best  perform  at  that  time,  because  technical  details 
are  not  frozen  and  line  personnel  are  not  as  adamant  about  change  as  they  are 
after  the  contract  is  received.  It  is  paradoxical  that  the  opportunity  for  the 
greatest  savings  exists  BEFORE  the  contractor  qualifies  for  sharing  under  the 
terms  of  any  VE  contract  clause.  On  large  competitive  procurements,  the 
definition  phase  of  the  system  procurement  provides  the  necessary  time  to 
perform  the  Value  Analysis.  On  sole  source  Cost  Plus  Fixed  Fee  (CPFF) 
procurements,  this  activity  is  best  done  during  the  preproposal  activities  or 
immediately  after  the  contract  is  received. 

The  necessity  of  valid  cost  data  cannot  be  overemphasized.  While  cost  data  is 
available  for  repetitive  operations  such  as  the  inputting  of  data  to  a  computer 
or  the  outputting  of  data  as  a  document,  they  are  not  available  for  system 
design,  or  program  design,  or  program  coding,  except  in  the  form  of  gross 
historical  data.  Cost  data  for  these  latter  subfunctions  need  to  be  carefully 
developed.  If  computer  program  VECPs  are  to  be  produced  during  the  system 
acquisition  phase,  some  means  must  be  developed  to  assign  a  dollar  value  to 
the  savings  accrued  from  a  reduction  in  computer  register  space  or  reduction 
in  program  operating  time. 

The  following  additional  points  on  VE  are  recommended  for  further  software 
procurement: 

A.  Initial  Use  of  VE 


For  software  companies  who  have  had  no  Value  Engineering  program 
in  existence,  a  minimum  of  three  months  should  be  allowed  to  set  up  a 
program.  Reasonable  costs  for  this  are  allowable  under  paragraph  1-1705.3  of 
ASPR. 
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B.  A  Program  Index  as  a  VE  Tool 


As  with  any  task,  tools  make  the  task  easier.  Within  the  past 
fifteen  years,  the  Air  Force  has  spent  millions  of  dollars  on  software.  In 
many  cases  it  has  paid  for  the  same  programming  function  more  than  once, 
because  both  the  Air  Force  and  the  contractor  were  unaware  that  the  function 
had  previously  been  programmed.  The  author  was  unable  to  determine  if  an  index 
or  catalog  exists  of  all  Air  Force-purchased  computer  programs,  computer 
program  systems,  and  computer  program  subroutines.  Such  an  index  of  all 
program  functions,  detailing  the  function,  the  language  used,  the  computer 
used,  etc.,  would  be  of  immense  value  to  a  software  Value  Engineer.  Programming 
of  mathematical  functions,  for  example,  could  easily  be  off-the-shelf  programming. 


C.  Early  Application  of  VE  Techniques 

The  dollar  advantage  of  applying  VE  techniques  as  early  as 
possible  in  the  contract  cannot  be  overstated.  With  contracts  lacking  a 
definition  phase.  Value  Analysis  is  best  accomplished  in  the  preproposal,  and 
Statement  of  Work  preparations.  While  this  is  advantageous  in  hardware 
procurement,  it  is  doubly  necessary  in  software  procurement.  With  few 
exceptions,  true  software  VE  changes  are  not  practical  after  the  SOW  has  been 
published.  A  true  software  change  is  one  requiring  a  change  to  the  computer 
program  requirements  and  a  concomitant  change  to  the  contract  or  Part  I  or 
Part  II  Specifications. 

D.  Cost  Tree 


As  early  as  possible  a  functional  cost  tree  should  be  prepared 
as  shown  in  Figure  1.  A  similar  chart  could  be  devised  for  any  software 
contract.  In  the  example  shown,  the  three  BUIC  CEIs  have  been  divided  into 
several  subfunctions.  The  chart  is  not  meant  to  be  complete  and  is  only 
shown  as  a  guide  for  laying  out  functional  costs.  Using  the  predetermined 
cost  of  each  CEI,  Value  Engineering  personnel  should  perform  a  detailed  cost 
analysis  for  each  major  function.  Those  functions  which  appear  to  have 
potential  cost  savings  should  be  assigned  a  target  cost  reduction  figure. 

This  figure  should  be  lower  than  the  contract-estimated  cost  and  should  be 
established  as  the  least  cost  required  to  perform  the  function.  Monitoring 
points  must  be  set  up  so  that  predicted  cost  expenditures  can  be  compared  with 
actuals  and  decisions  made  accordingly.  Some  functions,  such  as  installation, 
do  not  lend  themselves  to  a  new  target  cost. 

E .  Participation  of  VE  Personnel  at  Test  and  Design  Reviews 

It  is  mandatory  that  VE  personnel  participate  in  the  various 
reviews  and  tests  that  occur  during  the  acquisition  phase  of  a  system.  This 
includes  the  System  Design  Review  (SDR),  Preliminary  Design  Review  (PDR), 
Critical  Design  Review  (CDR),  First  Article  Configuration  Inspection  ( FAC  I ) , 
Preliminary  Qualification  Test  (PQT),  and  Final  Qualification  Test  (FQT) . 

Their  influence  can  be  felt  most  during  the  System  Design  Review  and  declines 
as  the  program  proceeds  through  its  acquisition  cycle. 
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APPENDIX  A 


First  2-Hour  Session 


1.  Definition  and  history  of  value  engineering  and  a  list  of 
applicable  references. 

2.  Types  of  value  engineering  contract  clauses,  and  responsibilities 
under  each  clause. 

3.  Percentage  of  total  contract  cost  to  be  spent  on  value  engineering. 

4.  Kinds  of  returns  expected  from  a  value  engineering  program. 

5.  Roadblocks  encountered  in  moutning  a  value  engineering  effort. 

Second  2-Hour  Session 

1.  Organization  and  responsibilities  of  a  value  engineering  office. 

2.  Approach  to  value  analyses. 

3.  Application  of  value  engineering  to  computer  program. 

4.  Necessity  of  obtaining  accurate  costs  for  value  engineering. 

5.  Selection  of  computer  program  functions  for  value  analysis. 

Third  2-Hour  Session 

1.  How  to  cost  a  VECP  for  computer  programs. 

Fourth  2-Hour  Session 

1.  How  to  initiate  and  process  a  VECP. 

2.  The  importance  of  schedules  in  a  VECP. 

Fifth  2-Hour  Session 

1.  Possible  pitfalls  and  problems  in  value  engineering. 

2.  Reporting  on  value  engineering. 

3.  Assessing  the  effectivity  of  a  value  engineering  program. 
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APPENDIX  B 

VALUE  ENGINEERING  REFERENCES 

1.  MIL-V-38352  dated  13  May  1964. 

2.  Armed  Services  Procurement  Regulation  (ASPR)  1-17,  dated  1  June  1967. 

3.  Value  Analysis/Value  Engineering,  by  the  AMA. 

4.  Techniques  of  Value  Analysis  and  Engineering,  by  L.  D.  Miles. 

5.  AFR  70-16  Value  Engineering,  dated  12  December  1963. 

6.  AD  614  612,  The  Management  of  a  Value  Engineering  Program  in  Defense 
Contracts,  April  1964. 

7.  H  111,  Value  Engineering  Handbook,  29  March  1963. 

8.  AD  600  394,  Value  Engineering,  October  1964. 

9.  AD  482  096,  Value  Engineering  Conference,  February  1964. 

10.  AD  618  070,  In-House  Value  Engineering,  June  1965. 

11.  AD  609  520,  Value  Analysis,  March  1963. 

12.  AD  609  883,  Instruction  Notes  for  Case  Problems  in  the  Contractual  Aspects 

of  Value  Engineering,  April  1964. 

13.  AD  624  810,  The  Application  of  Defense  Value  Engineering,  January  1966. 

14.  AD  604  663,  Principles  and  Applications  of  Value  Engineering,  1964. 

15.  AD  625  659,  Value  Responsibilities  of  the  Designer,  December  1965. 

16.  AD  605  454,  Fringe  Effects  of  Value  Engineering,  May  1964. 

17.  ASDP  70-1,  Procurement  Guide  to  Value  Engineering,  March  1963. 

18.  ESD  TR-66-282,  Advantageous  Definitions  Concerning  Value,  April  1966. 

19.  ORDP  40-2,  Value  Analysis,  August  1961. 

20.  TM-3225/000/01  ,  Management  Handbook  for  the  Estimation  of  Computer  Program 
Costs,  System  Development  Corporation,  20  March  1967. 
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